Google Cloud resource hierarchy
How is the Google Cloud resource hierarchy organized?
The Google Cloud resource hierarchy has four levels. All resources are created within a project.
The Google Cloud resource hierarchy has four levels: organization, folder, project, and resource. The Google Cloud project is a container for all the Google Cloud services. When a new resource is created in Google Cloud, it is always created within a project. Organizations and folders may have multiple projects, but a project may only have a single parent, an organization, or a folder, at a time.
Levels in the Google Cloud resource hierarchy
At the top level is an organization node, which encompasses all the projects, folders, and resources in your organization. The organization is at the top of the Google Cloud resource hierarchy. Metaphorically speaking, the Google Cloud resource hierarchy resembles the file system found in traditional operating systems as a way of organizing and managing entities hierarchically. The Google resource hierarchy can be conceived as a folder hierarchy similarly. In Google Cloud and AWS, each resource has exactly one parent.
Let's explore the levels in the Google Cloud resource hierarchy.
Click the + icons to learn more.
Policy inheritance
Policy inheritance
In Google Cloud, the hierarchical organization of resources lets you set access control policies and configuration settings on a parent resource.
Child resources inherit policies and IAM settings.
The child resources inherit the policies and IAM settings of the parent resource. Policies can be defined at the project, folder, and organization node levels. Some Google Cloud services allow policies to be applied to individual resources. For example, you can set policies on certain resources in BigQuery, Compute Engine, Pub/Sub, Cloud Storage, and many other services.
The Google Cloud resource hierarchy provides a hierarchy of ownership, which binds the lifecycle of a resource to its immediate parent in the hierarchy. It also delivers attach points and inheritance for access control and organization policies.
Organizations
Organization roles
Organization roles
An organization node is a root node for Google Cloud resources.
Organization roles include the Organization Admin and the Project Creator. The Organization Admin has control over all cloud resources. It is useful for auditing. The Project Creator controls project creation.
Let's consider these roles using an example.
Click the + icons to learn more.
Creating and managing organizations
Creating and managing organizations
The Organization resource is closely associated with a Google Workspace or Cloud Identity account.
When a user with a Google Workspace or Cloud Identity account creates a Google Cloud Project, an Organization resource is automatically provisioned for them. Then, Google Cloud communicates its availability to the Google Workspace or Cloud Identity super admins. These super admin accounts should be used carefully because they have a lot of control over your organization and all the resources underneath it.
The key roles for creating and managing organizations are Google Workspace super administrators, Cloud Identity super administrators, and the Google Cloud Organization admin roles. These roles are generally assigned to different users or groups, depending on the organization structure and needs. For example, these roles can be used during the setup process. They are also used at other points during the lifecycle control for the Organization resource, such as deleting the resource if it is no longer used.
Let's examine each role.
Click the tabs to learn more.
In the context of Google Cloud Organization setup, the responsibilities of the Google Workspace or Cloud Identity super administrator are the following:
- Assign the Organization admin role to some users.
- Be a point of contact in case of recovery issues.
- Control the lifecycle of the Google Workspace or Cloud Identity account and Organization resource.
The responsibilities of the Organization admin role are the following:
- Define IAM policies.
- Determine the structure of the resource hierarchy.
- Delegate responsibility over critical components such as Networking, Billing, and Resource Hierarchy through IAM roles.
Following the principle of least privilege, this role does not include the permission to perform other actions, such as creating folders. To get these permissions, an Organization admin must assign additional roles to their account.
Folders and projects
Folders
Folders
Google Cloud folders provide a way to organize Google Cloud Projects and other folders. They operate similarly to how AWS Organizational Units organize AWS Accounts.
Folders let you provide boundaries for different legal entities, departments, and teams. Let's explore how folders can help you structure your resource hierarchy and control access to your resources in Google Cloud.
Click the + icon to learn more.
Projects
Projects
When you work in Google Cloud, you need to remember these key points about projects:
- 1
Projects are separate entities under the Organization node (and optionally under folders).
- 2
Each project is a separate compartment to hold resources, each of which belongs to just one project.
- 3
Projects can have different owners and users, as they're billed and managed separately.
Each Google Cloud project has three identifying attributes: a project ID, a project name, and a project number. Let's examine each attribute.
Click the tabs to learn more.
The project ID is a globally unique identifier assigned by Google that cannot be changed–they are immutable–after creation. Project IDs are used in different contexts to inform Google Cloud of the exact project to work with.
Project names are user-created. They don’t have to be unique and they can be changed at any time, so they are not immutable.
Google Cloud also assigns each project a unique project number. It’s helpful to know that these Google-generated numbers exist, but they are mainly used internally, by Google Cloud, to keep track of resources.
Google Cloud's Resource Manager tool
So, how do you manage projects in Google Cloud?
Google Cloud has the Resource Manager tool, designed to programmatically help do just that. You may be familiar with the suite of tools AWS offers for managing resource hierarchies including AWS Organizations, AWS Control Tower, and AWS Resource Access Manager. AWS Organizations enable an administrator to create, update, and delete Organizational Units and apply Service Control Policies (SCPs) which serve as permissions guardrails for accounts within the organizational units. AWS Control Tower provides administrators the capability to set up guardrails and automation around account provisioning and assuring accounts are following the organization’s best practices. AWS provides the AWS Resource Access Manager for sharing resources across accounts within an organization.
Google Cloud's Resource Manager is an application programming interface (API) that can gather a list of all the projects associated with an account, create new projects, update existing projects, and delete projects. It can even recover projects that were previously deleted and can be accessed through the Remote Procedure Call (RPC) API and the REST API.
Let's explore some resource manager roles within the Google Cloud resource hierarchy.
Click the + icon to expand and learn more.
Admin: Full control over all resources
Viewer: View access to all resources
Admin: Full control over folders
Creator: Browse hierarchy and create folders
Viewer: View folders and projects below a resource
Creator: Create new projects (automatic owner) and migrate new projects into the organization
Deleter: Delete projects
Once a user creates a project, they're automatically granted the owner role for that project.
Initially, the project resource is owned by its creator exclusively. The creator can later grant permission to others to read or update the project. Several APIs are activated automatically for the project, including Google Cloud Storage.
AWS offers built-in and custom policies; Google Cloud offers built-in and custom roles.
- AWS refers to the collection of permissions and resources those permissions apply to as a policy. AWS lets the account root fully administer roles and policies unless otherwise restricted by a Service Control Policy. These policies can be attached to users, groups of users, or roles.
- Google Cloud offers sets of predefined roles, and they define where those roles can be applied. This provides granular access to specific Google Cloud resources and prevents unwanted access to other resources. These roles are collections of permissions because, to do any meaningful operations, you usually need more than one permission.
Best practices for setting up your resource hierarchy and permissions
As you set up a resource hierarchy in Google Cloud and set permissions, remember the following best practices.
- 1
Mirror your Google Cloud resource hierarchy structure to your organization structure. The Google Cloud resource hierarchy should reflect how your company is organized, whether it's a startup or a large corporation. A startup may start out with a flat resource hierarchy with no organization resource. When more people start collaborating on projects and the number of projects increase, getting an organization resource might make sense. An organization resource is recommended for larger companies with multiple departments and teams where each team is responsible for their own set of applications and services.
- 2
Use projects to group resources that share the same trust boundary. For example, resources for the same product or microservice can belong to the same project.
- 3
Grant roles to a Google group instead of to individual users when possible. It is easier to manage members in a Google group than to update an allow policy. Make sure to control the ownership of the Google group used in allow policies.
- 4
Use the security principle of least privilege to grant IAM roles; that is, only give the least amount of access necessary to your resources. To find the appropriate predefined role, see the predefined roles reference. If there are no appropriate predefined roles, you can also create your own custom roles. Grant roles at the smallest scope needed. For example, if a user only needs access to publish messages to a Pub/Sub topic, grant the Publisher role to the user for that topic. Remember that the allow policies for child resources inherit from the allow policies for their parent resources. For example, if the allow policy for a project grants a user the ability to administer Compute Engine virtual machine (VM) instances, then the user can administer any Compute Engine VM in that project, regardless of the allow policy you set on each VM.